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Sirs: 

Appellants respectfully replies to the Examiner's Answer, mailed July 28, 2008, in 
the following Brief. 
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I. STATUS OF CLAIMS 

Claims 1-6, 8-16, and 18-24 stand rejected under 35 U.S.C. § 103(a) as 
unpatentable over U.S. Patent Application Publication No. 2002/0178103 to Dan et al., 
hereinafter, Dan, in view of U.S. Patent Application Publication No. 2003/0167446 to 
Thomas, hereinafter, Thomas, and further in view of U.S. Patent Application Publication 
No. 2002/0042757 to Albazz et al, hereinafter, Albazz. 

Appellants respectfully traverse these rejections based on the following 
discussion. 

II. STATEMENT OF AMENDMENTS 

Appellants gratefully acknowledge the Examiner's communication, noting that an 
Amendment After Final was submitted on February 28, 2008. 

III. RESPONSE TO ANSWER'S ARGUMENTS 
A. The Dan Disclosure 

[0033] The TPA template or party profile may be included as part of the 
information advertised by the service provider in step 60 of FIG. 2. The profile 
serves as the starting point of a negotiation by providing an initial version of a 
contract document. The profile may include information such as: products and 
services provided, specific business processes that the service provider can 
perform, security requirements, and technology information such as which 
message-exchange protocols are supported by the service provider. The service 
provider's profile may be embodied in a variety of different forms. Several 
examples of the service provider's profile are described herein, although 
alternative profile forms will be apparent to those of ordinary skill in the art. 

[0034] In one embodiment, the service provider's profile may describe the 
capabilities of one party. This profile may be expressed, for example, as an XML 
document whose contents may be incorporated into a contract. The information 
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contained in the profile may include not only the capabilities of a party but also 
may contain requirements of the interacting party in the form of a contract 
template. The contract template is provided to express a contract either between a 
pair of roles or between an actual party (whose profile is represented by the 
template) and a role. One example of a contract template is an almost-complete 
electronic contract document with a few fields left blank: these fields are to be 
filled in by the negotiating party. An enhanced template additionally specifies, in 
an associated document, the acceptable choices for the negotiable fields. 

[0035] Fig. 4 is a schematic diagram that illustrates a party profile and a 
contract template. Party profile 1010 may contain, for example, party contact 
information 1011, a description of the service offered or needed 1012, one or more 
contract templates 1013, and allowable choices 1014. Allowable choices 1014 
may cover, for example, business and/or technical considerations such as a list of 
supported transport protocols, a list of supported shipping or transport services 
(such as overnight shipping, airmail delivery, etc.), delivery times, and/or the 
optional use of a preexisting meta contract. Profile 1010 may include a contract 
template 1020 containing one or more nonnegotiable fields 1021, 1022 and one or 
more negotiable fields 1023, 1024. As mentioned above, negotiable field 1023 or 
1024 may be treated as a blank that may be completed by the negotiating party or, 
alternatively, may specify capabilities or allowable choices that may be selected. 
The capabilities and/or allowable choices may be provided as searchable 
information by a public registry or repository. 

[0046] If either of the parties chooses to abort 340 the negotiation at any 
time during negotiations, the outcome 350 is the termination of the entire 
negotiation process. When all the sub components of a contract have been agreed 
to by both sides, the negotiation is committed in step 360, and the negotiation 
continues to step 380 where the negotiation is complete and step 380 leads to the 
service contract or TPA. 
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B. The Thomas Disclosure 

[0044] Once the user has finished entering modifications to the XML file 
and all of the modifications have been found to be either not significant or valid 
semantic changes, the temporary version of the XML file in the RAM 7 is written 
over the original file in the first storage region. Of course, the modified version 
of the XML file may be stored separately from the original version of the XML 
file instead of overwriting the original XML version. 

C. The Albazz Disclosure 

[0076] A product List Filter (PLF) is a representation of a seller's product 
list which replaces the completer list of all products available from a seller 
organization (as used herein the term "products" includes both products and 
services). This representation comprises product selection and/or exclusion 
criteria, based on a selection metaphor. The representation criteria are structured 
and stored in a way that ensures rebuilding the targeted product list from a master 
product catalog, or from multiple catalogs or other product information sources, 
any time the target product list is required. Depending upon the used PLF, a 
generated list could be static with the same products being produced at every run, 
or could be dynamic with new products being added or removed according to 
changes taking place at the seller organization. Fig. 5 illustrates an example of 
the creation and storage of a Product List Filter. 

D. Arguments 

Regarding the rejection of independent claims 1,11, and 21, the Answer cites Dan 
for teaching "pre-building static structures of said XML transaction (Paragraphs 33-35)". 

Dan discloses a contract template 1011, presumably analogous to a business 
transaction, containing one or more nonnegotiable fields 1021, 1022 and one or more 
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negotiable fields 1023, 1024. Dan also discloses that the profile serves as the starting 
point of a negotiation by providing an initial version of a contract document, i.e., the 
contract template, 1011. (Paragraph [0035]). 

The present invention defines a "static structure" as "a pre -built XML structure 
with pre-filled values based on the associated transaction type and TPP [Trading Partner 
Profile]", (Specification, paragraph [0024], lines 13-15). Therefore, the pre-built XML 
"static structures" of the present invention are static, i.e., unchanging, and pre-filled with 
values based on the associated transaction type and trading partner profile. Hence, there 
are no negotiable fields, as described by Dan, in the invention's static structures, which 
are static and pre-filled. 

In contrast, the contact template of Dan contains one or more negotiable fields 
1023, 1024 that will be filled with future negotiations. 

Therefore, Appellants respectfully submit that Dan does not disclose, teach or 
suggest the present invention's feature of "pre-building static structures of said XML 
transaction, wherein said static structures comprise a pre-built XML data structure with 
pre-filled values based on a transaction type of said XML transaction and a 
predetermined trading partner profile", as recited in independent claims 1,11, and 21. 

Regarding the rejection of independent claims 1,11, and 21, the Answer cites 
Thomas for teaching "wherein said final XML structure is validated by comparing said 
final XML structure against said copy of said original pre-defined data type definition 
format for said XML transaction" as "Once the user has finished entering modifications to 
the XML file and all of the modifications have been found to be either not significant or 
valid semantic changes, the temporary version of the XML file in the RAM 7 is written 
over the original XML file in the first storage region 4" (Paragraph 44 [of Thomas]). 

In the present invention, a business partner agrees to send a business transaction in a 
mutually agreed upon XML format (proprietary or standards based), call a Data Type 
Definition (DTD) format. Next, a Trading Partner Profile (TPP) is created in a database 
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that holds information about the partner, the communication protocol used, the enabled 
transaction, format of transaction, and XML format version. Then, a copy of the DTD is 
created. Thereafter, static elements of the XML are filled with pre-determined values 
based on the TPP and are stored using an editor. The static sections are linked to the TPP 
and transaction , and are stored in the database. At execution time , based on the TPP and 
transaction combination, the corresponding static sections are taken and the application 
specific dynamic sections are built to construct the final XML . Execution time is defined 
as the transaction runtime (that is, sending the transaction to the trading partner). The 
constructed XML is then run against (compared against) the DTD to validate the structure . 

In contrast, Thomas discloses that the temporary copy of the contents of the XML 
file is displayed 29 by means of the output interface 10 so that a user is able to input 
modifications to the XML file via the input interface 9. Each of the changes entered by the 
user is compared 30 to the temporary copy of the XML file and checked 31 to establish 
whether the modification is significant, i.e., a semantic change. . . . Where the modification 
is identified as a semantic change, the processor checks 34 whether a valid difference 
representation of the change can be generated using the delta DTD [i.e., Document Type 
Definition] . 

Thomas further discloses a method of recording and validating changes to a markup 
language, wherein semantic changes to the original XML file necessarily require slight 
modifications to enable a delta file to represent changes to the original markup language 
file. These slight modifications may entail amending element type declarations and 
processing these element type declarations to the lowest level of each content particle. 

However, the DTD of the present invention is originally fixed and its DTD copied, 
and does not require such slight modifications or amending of element type declarations as 
does Thomas because the final XML structure of the present invention comprises pre-filled 
static structures, to which no modifications or amendments of the DTD are made, and 
dynamic structures that comprise empty tags, to which no modifications or amendments of 
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the DTD are made, so that the final or constructed XML structure may be compared to or 
validated against the original pre-defined data type definition. 

Therefore, Appellants respectfully submit that Thomas does not disclose, teach or 
suggest the present invention's feature of "wherein said final XML structure is validated 
by comparing said final XML structure against said copy of said original pre-defined data 
type definition format for said XML transaction", as recited in independent claims 1,11, 
and 21. 

Furthermore, for at least the reasons outlined immediately above, Appellants 
respectfully submit that Thomas does not cure the deficiencies of Dan, because Thomas 
does not disclose, teach or suggest the present invention's feature of "pre-building static 
structures of said XML transaction, wherein said static structures comprise a pre-built 
XML data structure with pre-filled values based on a transaction type of said XML 
transaction and a predetermined trading partner profile". 

Instead, Thomas merely discloses a method of recording and validating changes 
to a markup language, wherein semantic changes to the original XML file necessarily 
require slight modifications to enable a delta file to represent changes to the original 
markup language file. 

Regarding the rejection of independent claims 1,11, and 21, the Answer cites 
Albazz for teaching "building a list of a sequence of said static and dynamic structures". 

Appellants respectfully submit that Albazz merely discloses generating a list that 
could be static with the same products being produced at every ran, or could be dynamic 
with new products being added or removed according to changes taking place at the seller 
organization. 

In contrast, the present invention describes the feature of "building a list of a 
sequence of said static and dynamic structures", wherein both static and dynamic structures 
are previously defined , i.e., "pre-building static structures of said XML transaction, 
wherein said static structures comprise a pre-built XML data structure with pre-filled 
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values based on a transaction type of said XML transaction and a predetermined trading 
partner profile; classifying dynamic structures of said XML transaction with empty tags 
and single occurrence classifiers for repeating dynamic structures". 

The static and dynamic product lists of Albazz do not disclose, teach or suggest the 
present invention's features of "wherein said static structures comprise a pre -built XML 
data structure with pre-filled values based on a transaction type of said XML transaction 
and a predetermined trading partner profile" or "dynamic structures of said XML 
transaction with empty tags and single occurrence classifiers for repeating dynamic 
structures". The static and dynamic product lists of Albazz are not explicitly defined as 
XML data structures corresponding to a transaction . A list is not a transaction. 

Therefore, Appellants respectfully submit that Albazz does not disclose, teach or 
suggest the present invention's feature of "pre-building static structures of said XML 
transaction, wherein said static structures comprise a pre-built XML data structure with 
pre-filled values based on a transaction type of said XML transaction and a predetermined 
trading partner profile; classifying dynamic structures of said XML transaction with empty 
tags and single occurrence classifiers for repeating dynamic structures; building a list of a 
sequence of said static and dynamic structures", as recited in independent claims 1,11, and 
21. 

Furthermore, for at least the reasons outlined immediately above with respect to 
Albazz and above with respect to Dan and Thomas, Appellants respectfully submit that 
Albazz does not cure the deficiencies of Dan and Thomas, because Albazz also does not 
disclose, teach or suggest the present invention's feature of "pre-building static structures 
of said XML transaction, wherein said static structures comprise a pre-built XML data 
structure with pre-filled values based on a transaction type of said XML transaction and a 
predetermined trading partner profile". Instead, Albazz merely discloses generating a list 
that could be static with the same products being produced at every run, or could be 
dynamic with new products being added or removed according to changes taking place at 
the seller organization. 
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For at least the reasons outlined above, Appellants respectfully submit that Dan, 
Thomas, and Albazz, either individually or in combination, do not disclose, teach or 
suggest the present invention's features of "pre-building static structures of said XML 
transaction, wherein said static structures comprise a pre-built XML data structure with 
pre-filled values based on a transaction type of said XML transaction and a predetermined 
trading partner profile; classifying dynamic structures of said XML transaction with empty 
tags and single occurrence classifiers for repeating dynamic structures; building a list of a 
sequence of said static and dynamic structures", as recited in independent claims 1,11, and 
21. Accordingly, Dan, Thomas, and Albazz, either individually or in combination, fail to 
render obvious the subject matter of independent claims 1,11, and 21, and dependent 
claims 2-6, 8-10, 12-20, and 21-24 under 35 U.S.C. §103(a). 

In view of the foregoing, the Board is respectfully requested to reconsider and 
withdraw the rejection of independent claims 1, 11, and 21 and dependent claims 2-6, 8- 
10, 12-20, and 21-24 under 35 U.S.C. § 103(a) as unpatentable over Dan, Thomas, and 
Albazz 
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VIII. CONCLUSION 

In view of the foregoing, the Appellants respectfully submit that the collective 
cited prior art do not teach or suggest the features defined by independent claims 1,11 
and 21, and as such, claims 1,11, and 21 are patentable over Dan, Thomas and Alabazz, 
either individually or in combination. Furthermore, as the independent claims are 
patentable over Dan, Thomas, and Albazz, so too are dependent claims 2-6, 8-10, 12-16, 
18-20, and 22-24 patentable over Dan, Thomas and Albazz by virtue of their dependency 
from patentable independent claims 1,11, and 21. Thus, Appellants respectfully request 
that the Board reconsider and withdraw the rejections of claims 1-6, 8-16, and 18-24 and 
pass these claims to issue. 

Please charge any deficiencies and credit any overpayments to Attorney's Deposit 
Account Number 09-0456. 

Respectfully submitted, 



Date: September 29. 2008 /Peter A. Balnave/ 

Peter A. Balnave, Ph.D. 
Registration No. 46,199 

Gibb & Rahman, LLC 
2568-A Riva Road, Suite 304 
Annapolis, MD, 21401 
Voice: (410) 573-5255 
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